鐵人賽最終回，來談談雲端應用程式的應用程式架構設計所需要考量的事情吧。
Cloud Computing在2008年出現後，已經成為資訊產業的焦點領域，各大主流廠商無不投入雲端運算的領域中，台灣的主要軟硬體與系統商（趨勢科技、英業達等）也投入大量人力與資本到雲端運算的市場中，工研院也發展了自己的雲端作業系統Cloud OS 1.0進入雲端領域中，Google, Amazon與Microsoft更是不斷的擴充與強化自己的雲端運算實力，以吸引不同的產業與廠商進入雲端的世界。不過雲端運算的思維和一般應用程式有著極大的不同，若應用程式的開發人員無法理解雲端與一般應用程式的差異時，很容易設計出只使用雲端一點點資源的一般應用程式而已，完全無法發揮雲端運算的威力。
平常我們在程式設計書籍（入門等級）上所讀到與學到的，都是一般應用程式的開發方式，以ASP.NET為例，書上不太會教在高度負載的網路環境中的應用程式設計，所以多數的開發人員可能都不知道ASP.NET的程式如何設定狀態管理機制以支援負載平衡（Load Balancing）的網路架構，亦或是不知道程式和服務（Service）的差別，更不會知道分散式應用程式的設計方式。我們會學到的永遠都是Request.Form、控制項事件、Response.Redirect、ADO.NET、Master Page、Site Map或是網頁的設計，這些全都是一般應用程式的作法，很適合小型的Web應用程式的開發，小型的應用程式環境也不會太複雜，最多就只是一台或兩台伺服器上運行一種或數種應用程式，不會有太多流量，也不需要做Load Balancing或Failover Cluster（容錯叢集），網路環境也很單純（只有區域網路）。
不過在雲端運算的應用程式環境，不再只是單純的一兩台伺服器，而是數千至數萬個虛擬機器（Virtual Machine），網路環境是在資料中心內錯綜複雜的VLANs或是多網段系統，資料庫可能是在不同網段內，儲存環境是分散性的架構，應用程式執行的VM有可能因為虛擬機器的回收或是機器的切換而可能會不同，原有Session的架構無法在雲端運算環境的VM上使用（若VM移轉時Session會消失）；資料無法只存在本地，而必須存在遠端儲存中；SQL Server資料庫連線與存取方式會有點不同等，雲端環境的無限運算彈性考驗著應用程式的設計機制，一般應用程式基本上是很難在雲端運算環境上生存的，雲端環境和平常使用的環境而言，用天與地的差別來比喻實有過之而無不及。
為了要能夠讓應用程式可以順利的進入雲端環境，首先，應用程式的開發人員要先了解雲端應用程式和一般應用程式的差別；了解現有的應用程式架構是否能支援或適配於雲端環境；應用程式可用的架構手法；以及移轉應用程式的可行方案等等，在設計與規劃雲端應用程式時心裡才會有一個底，設計出的應用程式就不會偏差太多。
雲端應用程式（Cloud Application）是可運行在雲端環境上的應用程式，通常是指Web應用程式，但基於網路服務型態的服務應用程式（Service Application）也可算是一種雲端應用程式，雲端應用程式有個一般應用程式無法達成的特色，就是能完全利用雲端運算平台幾近無限的運算、儲存與網路資源等，應用程式可以配合企業的需求動態擴充（Scalable），以支援大量的運算需求，或是在需求量縮時，動態的調降運算資源量，以節省企業的IT支出成本。
為了達成可支援伺服器擴充時的運行需求，應用程式至少要支援下列能力：
以微軟的ASP.NET來說，ASP.NET 2.0開始已內建了不同的Session State儲存機制，微軟也釋出了支援Table Storage的Session State Provider，讓開發人員得以輕易的將狀態資料移轉到SQL Azure或是Table Storage中，以支援Load Balancing的功能。而Windows Azure Platform上亦提供了獨立的分散式儲存（Distributed Storage），可供應用程式保存資料，讓分散式的應用程式可自由的保存與使用資料。
雲端應用程式還有一個一般應用程式所沒有的特色：全球化（Globalization），雲端應用程式的用戶端來源可以是全球各地，而應用程式可自由的於雲端供應商在各地所建設的資料中心自由的部署，若應用程式需要支援全球化的使用者時，雲端應用程式必須要可快速且按企業的需求於不同的資料中心產生應用程式的執行環境，在最短時間內服務當地或該區域內的用戶端，這點也一般應用程式無法做到的（如果要做到，需要在全球廣設資料中心）。這點可以依賴雲端供應商的資料中心達成，Windows Azure Platform在全球六個地區設置了大型的資料中心，可支援大多數雲端應用程式的快速部署需求。
企業若想要將現有運行在本地環境的應用程式移轉到雲端環境時，必須要先檢視應用程式本身的架構是否符合雲端運算的環境，當應用程式無法滿足於雲端環境執行的條件時，則需要修改應用程式，這個步驟稱為升級（Upgrade）或移轉（Migration），事實上，大多數的應用程式都需要在搬上雲端前升級，否則可能會無法運用雲端的特性，或是根本無法於雲端環境上執行。
大多數的應用程式檢測都可以先在本地的模擬環境中先測出，像Windows Azure SDK內附的Computes Emulator以及Storage Emulator都能模擬出雲端實際的環境，應用程式可以充份利用模擬環境來測試自己的應用程式是否可以順利執行在雲端環境中。順利執行是一回事，充份運用雲端運算資源才是終極的目標，否則只是把雲端當做一個Hosting的環境而已。
適當的選用雲端平台上的資源，也是開發雲端應用程式的重點項目之一，以Windows Azure Platform為例，就有Web Role、Worker Role和VM Role三種，VM的規模則是分為五種，要如何適當的運用這些資源，以最少的成本獲得最大的利益呢？在發展的設計初期就要考量，像是預期使用人數，系統架構，各元件的責任，資料的規模以及處理的複雜度等，這些因素會組合成選擇的指標，例如Web Role適用於處理前端的工作或是掛載HTTP服務，而Worker Role適合後端運算的處理，也可以引入MapReduce的多重分散式運算架構，搭配不同的storage service和SQL Azure，組合成整個應用程式的架構。微軟曾在MSDN中發表一個雲端的範例應用程式Tailspin Sample Application，它就利用了不同的Role來實作應用程式的整體架構。
如果是想要做軟體服務（Cloud Software）的話，那麼**多租架構（Multi-tenant）**就是重點了，如何保有資料的隔離性以及應用程式最高的可維護性，也是在架構設計時就要思考的問題，不同的案例會有不同的作法，微軟則提供了Fabrikam SaaS Sample Application給開發人員和架構設計人員作為參考之用，同時也有線上的Live Demo試用。
最後，說了這麼多，最重要的還是轉換思維，不能將雲端的應用程式當成一般的應用程式來設計，一定要用雲端的架構思維來分析與設計應用程式架構，否則一旦架構設計失當的話，對應用程式的開發與維運是很大的問題，嚴重的話還可能要整個『砍掉重練』，與其要這麼大費周章，不如一開始就做好設計和規劃，讓應用程式真的能善用雲端的資源，以最小成本獲取最大的利益。
Reference:
http://msdn.microsoft.com/en-us/library/ff966486.aspx
http://msdn.microsoft.com/en-us/library/ff966499.aspx
http://msdn.microsoft.com/en-us/library/ff728592.aspx
http://www.fabrikamshipping.com/
studyazure提到：
，事實上，大多數的應用程式都需要在搬上雲端前升級，否則可能會無法運用雲端的特性，或是根本無法於雲端環境上執行。
難怪我老婆說，雜誌上有寫，5年後只留一種程式員，就是雲端程式員，
只是要了解那麼多事情，才能上雲端，我看一般程式員爆肝後上雲端。
看到很多商業競爭上的廣告術語，在IT這個行業，有時候，表面上要裝飾得很friendly，
但是為了和其他競爭者區隔，要把一些二/三十年前的術語換成別一組術語。
這種收費制度的設計，感覺就像"大量授權"， 授權書上，條文一大堆，付了錢，但是沒有什麼售後服務。
未來雲端的"保全"，應該會很火熱吧，我們政府應該也多關注這塊軟實力，別再2兆傷心，光電/太陽能慘業了。
比較少人分享亞馬遜的雲端，畢竟它比google更是純商業化的雲端 。
iThome鐵人賽
看影片追技術